The SDK raced the whole verification against a fixed 60s wall: loading the
module, running it, and the round-trip that follows. That is a duration the SDK
is not in a position to judge. Which verification runs is decided by the backend
per request, long after the bundle shipped, and what it does varies from waiting
on a person to transferring data over an unknown connection, so no single number
is right for all of them. When the wall tripped, a verification that was
progressing normally was aborted and reported to the user as a timeout, and
because retrying restarts the work from the beginning, any connection slow
enough to trip it once would trip it again.

The bound now covers only loading the module, and stops there: once the module
takes control it governs its own duration and the SDK imposes no limit. The
default is 60s, deliberately generous, because nothing legitimate waits on this
timer — its only job is a connection that is accepted and then never answered,
since every other load failure already rejects on its own, a blocking
Content-Security-Policy included.

challenge_load_timeout_ms overrides that default, on a loader or on the
instance, resolved loader first. Per loader because loaders roll out gradually:
while a new one ramps two are live for the same instance at once, and the new one
may need a different value from the one it replaces. Which loader a browser was
assigned is a random draw per page load and cannot be recomputed from the config,
so Protect reports what the applied loader asked for.

Absent means "inherit" at both levels, so the default stays one number under our
control rather than being frozen into stored settings.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…edence

Three defects a second-model review found in the load bound.

An abort landing while the import was stalled settled nothing: the signal was
not part of the race, so an unmounted component kept the promise, its closures
and its timer alive for the whole bound and then reported a load failure for
what was a cancellation. The signal is raced now and rejects as
protect_check_aborted, matching the contract every other path already honours.

setTimeout stores its delay in a signed 32-bit int, so a configured value above
2^31-1 overflowed and fired immediately — failing every load instantly, which is
the exact opposite of what an operator asking for a long timeout wanted. The
value is clamped, and non-finite values fall back to the default rather than
being passed to the timer.

The precedence doc and the code disagreed. The doc said an absent loader value
inherits the instance-wide one, while the code takes the first APPLIED loader
that specifies one — so a value set on one of two live loaders would apply to
browsers that got the other. The code is the sensible rule, since there is no
single "the" loader once more than one is live, so the doc now states it and
warns that an instance running two loaders should set this on both or neither.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>